In older systems from the prior art, configuring the user interface was part of the respective application's code. However, this led to the user interface also having to be concomitantly changed when changing or updating the code. This led to increased programming and maintenance complexity.
In order to avoid this disadvantage, web browsers, in particular, have hitherto been used together with a markup language (the Hypertext Markup Language (HTML)) in order to be able to generate user interfaces which are at least very largely independent of the target system's parameters, for example the resolution and the respective platform. The mechanism on which HTML is based provides for “tags” to be used to prescribe the manner in which a particular part of a document is to be presented by an application, for example a WWW browser. However, the HTML-based procedure of the prior art requires a high level of programming complexity, since HTML is restricted in many respects.
A HTML-based application, for example, therefore needs to be interpreted by a browser which is generally not designed to execute applications. This leads to long processing times.
The HTML-based generation of user interfaces furthermore requires that, for a new user with different parameters for the user interface, for example a different resolution, one and the same application must be rewritten for the changed requirements associated with the new user.
User interfaces which can be changed dynamically when the application is running can also scarcely be generated or can be generated only with a very high level of complexity and high susceptibility to error. The previous procedure therefore holds some disadvantages.